Performance Evaluation of Transaction Processing Systems

Transaction processing Performance and price systems are complex in /performance are important nature and are usually attributes to consider when characterized by a large evaluating a transaction number of interactive processing system. Two terminals and users, major approaches to a large volume of onperformance evaluation line data and storage are measurement and devices, and a high modeling. TPC Benchmark volume of concurrent and A is an industry standard shared database accesses. benchmark for measuring Transaction processing a transaction processing systems require layers of system's performance software components and and price/performance. hardware devices to work Digital has implemented in concert. Performance TPC Benchmark A in a and price/performance are distributed transaction two important attributes processing environment. for customers to consider Benchmark measurements were when selecting transaction performed on the VAX 9000 processing systems. Model 210 and the VAX 4000 Performance is important Model 300 systems. Further, because transaction a comprehensive analytical processing systems are model was developed and frequently used to operate customized to model the the customer's business performance behavior of TPC or handle mission-critical Benchmark A on Digital's tasks. Therefore, a certain transaction processing level of throughput and platforms. This model was response time guarantee are validated using measurement required from the systems results and has proven to during normal operation. be an accurate performance Price/performance is prediction tool. the total system and maintenance cost in Introduction dollars, normalized by the performance metric. Digital Technical Journal Vol. 3 No. 1 Winter 1991 1 Performance Evaluation of Transaction Processing Systems The performance of a Modeling uses simulation transaction processing or analytical modeling system is often measured techniques. Compared to by its throughput in the measurement approach, transactions per second modeling makes it easier (TPS) that satisfies a to produce results and response time constraint. requires less computing For example, 90 percent resources. Performance of the transactions must models are also flexible. have a response time that Models can be used to is less than 2 seconds. answer "what-if" types This throughput, qualified of questions and to provide by the associated response insights into the complex time constraint, is called performance behavior of the maximum qualified transaction processing throughput (MQTh). In a systems, which is difficult transaction processing (if not impossible) to environment, the most observe in the measurement meaningful response time environment. Performance definition is the endmodels are widely used in to-end response time, research and engineering i.e., the response time communities to provide observed by a user at a valuable analysis of terminal. The end-to-end design alternatives, response time represents architecture evaluation, the time required by all and capacity planning. components that compose Simplifying assumptions the transaction processing are usually made in system. the modeling approach. The two major approaches Therefore, performance used for evaluating models require validation, transaction processing through detailed simulation system performance are or measurement, before measurement and modeling. predictions from the models The measurement approach is are accepted. the most realistic way of This paper presents evaluating the performance Digital's benchmark of a system. Performance measurement and modeling measurement results from approaches to transaction standard benchmarks have processing system been the most accepted form performance evaluation. The of performance assessment paper includes an overview of transaction processing of the current industry systems. However, due standard transaction to the complexity of processing benchmark, the transaction processing TPC Benchmark A, and a systems, such measurements description of Digital's are usually very expensive, implementation of the very time-consuming, and benchmark, including the difficult to perform. distinguishing features of the implementation and the benchmark methodology. The 2 Digital Technical Journal Vol. 3 No. 1 Winter 1991 Performance Evaluation of Transaction Processing Systems The benchmark can be run in either a local area network (LAN) or a wide area network (WAN) configuration. The related performance measurement throughput metrics are results that were achieved tpsA-Local and tpsA-Wide, by using the TPC Benchmark respectively. The benchmark A are also presented. specification defines Finally, a multilevel the general application analytical model of the requirements, database performance behavior of design and scaling rules, transaction processing testing and pricing systems with response time guidelines, full disclosure constraints is presented report requirements, and and validated against an audit checklist.[1] measurement results. The following sections provide an overview of the TPC Benchmark a-an Overview benchmark. The TPC Benchmark A Application Environment simulates a simple banking The TPC Benchmark A environment and exercises workload is patterned key components of the after a simplified banking system under test (SUT) application. In this model, by using a simple, updatethe bank contains one intensive transaction type. or more branches. Each The benchmark is intended branch has 10 tellers and to simulate a class of 100,000 customer accounts. transaction processing A transaction occurs when a application environments, teller enters a deposit not the entire range of or a withdrawal for a transaction processing customer against an account environments. Nevertheless, at a branch location. Each the single transaction teller enters transactions type specified by the at an average rate of one TPC Benchmark A standard every 10 seconds. Figure 1 provides a simple and illustrates this simplified repeatable unit of work. banking environment. Digital Technical Journal Vol. 3 No. 1 Winter 1991 3 Performance Evaluation of Transaction Processing Systems Transaction Logic an account, updates the The transaction logic current cash position of of the TPC Benchmark A the teller and branch, workload can be described and makes an entry of the in terms of the bank transaction in a history environment shown in Figure file. The pseudocode shown 1. A teller deposits in in Figure 2 represents the or withdraws money from transaction. Terminal Communication o The tested system must For each transaction, the preserve the effects of originating terminal is committed transactions required to transmit data and ensure database to, and receive data from, consistency after the system under test. The recovering from data sent to the system The failure of under test must consist of a single durable at least 100 alphanumeric medium that contains data bytes, organized as database or recovery at least four distinct log data fields: Account_ID, Teller_ The crash and reboot ID, Branch_ID, and Delta. of the system The Branch_ID identifies The loss of all or the branch where the teller part of memory is located. The Delta is the amount to be credited o Eighty-five percent of to, or debited from, the the accounts processed specified account. The data by a teller must belong received from the system to the home branch under test consists of (the one to which the at least 200 data bytes, teller belongs). Fifteen organized as the above percent of the accounts four input fields and processed by a teller the Account_Balance that must be owned by a results from the successful remote branch (one to commit operation of the which the teller does transaction. not belong). Accounts Implementation Constraints must be uniformly distributed and randomly The TPC Benchmark A imposes selected. several conditions on the Database Design test environment. o The transaction The database consists processing system must of four individual files support atomicity, /tables: Branch, Teller, consistency, isolation, Account, and History, and durability (ACID) as defined in Table 1. properties during the The overall size of the test. database is determined by the throughput capacity of the system. Ten tellers, each entering transactions at an average rate of 4 Digital Technical Journal Vol. 3 No. 1 Winter 1991 Performance Evaluation of Transaction Processing Systems store the history records one transaction every 10 generated during 90 eightseconds, generate what is hour days of operation at defined as a one-TPS load. the published system TPS Therefore, each teller capacity. For a system that contributes one-tenth (1 has a processing capacity /10) TPS. The history area of x TPS, the database is must be large enough to sized as shown in Table 2.